The present invention relates to computer frame buffer controllers, and more particularly to interface logic in a frame buffer controller for converting pixel data into a standard format for storage in the frame buffer when that pixel data was received in any of a number of predefined pixel formats and was communicated to the frame buffer controller by means of a bus that may operate in a big-endian or little-endian mode.
In computer systems, it is known in the art to utilize a computer graphics controller to serve as an interface between a video frame buffer, such as a video random access memory (VRAM), and other system components, such as one or more central processing units (CPIJs) and other video input resources. Typically, the video frame buffer is coupled to the other system components by means of a system bus which conveys both address and pixel data information. The frame buffer stores pixel data that is intended to be retrieved and converted, as necessary, for display on an image display device, such as a cathode ray tube (CRT). The hardware which retrieves the pixel data from the frame buffer for conversion and presentation to the image display device is known in the art as a random access memory digital-to-analog converter (RAMDAC). The RAMDAC is not usually coupled to the system bus, but instead is coupled to a special port for accessing the frame buffer. This port is called a serial access memory (SAM) port.
In order for a RAMDAC to perform the job of converting pixels retrieved from the frame buffer for display on an image display device, it is necessary that the pixels be stored within the frame buffer in a uniform format that is compatible with the RAMDAC's mode of operation. However, pixels may be encoded in any of a number of well-known formats (such as RGB 8 bpp, RGB 16 bpp, RGB 32 bpp and YUV 16 bpp), and it cannot be generally assumed that a pixel-generating device or application program will output pixels in a format that is compatible with that which is required, by the RAMDAC, to be stored into the frame buffer. In such cases, some intermediating mechanism for converting the pixels from one format into another is required. It is noted that such a conversion mechanism may have to be bi-directional if a computer resource expects to write and read pixels to/from the frame buffer in a format that is incompatible with that which is required by the RAMDAC.
In the past, such conversion has been performed by the pixel data source itself. For example, a processor that generates pixel data having an incompatible format might subject the pixels to conversion software before transmitting them to the frame buffer. Of course, if the pixels are subsequently read back from the frame buffer, then the processor would have to subject the received pixels to a reverse conversion algorithm before supplying them to an application program that is expecting the incompatible format. This technique suffers from a number of drawbacks, not the least of which is the fact that the processor must always "know" what pixel format the RAMDAC is expecting to see. This solution is also inefficient, since it requires that the conversion process be performed by each and every pixel generating device that uses an incompatible pixel format.
U.S. Pat. No. 5,301,272, which is incorporated herein by reference, describes an alternative solution that permits the frame buffer controller to recognize when a received pixel is supplied in a pixel format that is incompatible with that which should be used for storage into the frame buffer. With this capability, the necessary conversion logic can be centrally located within the frame buffer controller itself, thereby eliminating the need to perform conversion in the pixel-generating units, as in previous solutions. As described in the cited U.S. patent, the capability relies on the use of address aliasing. That is, a "pixel type tag" is included as part of the frame buffer address that accompanies the pixel when it is transmitted to the frame buffer controller. The pixel type tag indicates to the frame buffer controller the format in which the pixels are encoded. It is up to the frame buffer controller to include the necessary logic to decode the pixel type tag and perform the necessary operations to convert the received pixels into the format that is to be stored into the frame buffer.
The pixel conversion problem is made even more difficult by the fact that a number of well-known bus standards have evolved which are incompatible with one another. For example, one bus type may utilize separate address and data lines, while another bus type may multiplex a common set of lines to communicate address and data information. This type of incompatibility, which does not pose significant problems in relation to frame buffers, may be handled by appropriate hardware contained within a bus bridge for allowing devices on one of the buses to communicate with devices connected to the other bus.
However, another type of bus incompatibility, namely "endian-ness incompatibility", does introduce complications related to the goal of converting pixels from one format to another. The endian-ness of a bus refers to the fact that multiple bits, bytes, words, etc., may be communicated in parallel on a bus, with addresses also being provided to refer to particular ones of the bits, bytes, words, etc. Take, for example, the case where the granularity of an address is down to the byte level (i.e., increasing an address by 1 refers to a next byte of data), and a data bus is capable of transferring four bytes in parallel. In a big-endian ("BE") system, a first address would refer to the most significant (i.e., left-most) byte on the data bus, and increasing addresses refer to increasingly less significant bytes. By contrast, in a little-endian ("LE") system, that same first address would refer to the least significant (i.e., right-most) byte on the data bus, and increasing addresses point to increasingly more significant bytes.
To resolve this general incompatibility, bus bridges have applied a rule of "address invariance", wherein the bytes (or whatever size data unit corresponds to the granularity of bus addresses) on a bus are swapped, end-for-end, whenever they cross from one bus to another. This byte-swapping is illustrated in FIG. 1.
While byte-swapping may enable compliance with the address invariance requirements of standardized buses, it does not, in general, enable pixels received from, say, a LE bus to be stored into a BE frame buffer because while the byte swapping guarantees that pixels are placed into their proper location on the bus (i.e., address and byte-lanes), bytes within a pixel can be swapped, thereby causing that pixel to be garbled. An illustration will help make this point clear.
Suppose pixels are encoded in an .alpha.RGB 16 bpp (bits per pixel) format. In such a format, .alpha. is represented by 1 bit, and the R, G and B codes are each represented by 5 bits of data. In our previous example, where the data bus is capable of conveying 4 bytes of data, a LE system would transmit two pixels per bus cycle in the format shown in FIG. 2A. If the destination of the pixels is a BE frame buffer, the pixels will undergo the byte swapping previously illustrated in FIG. 1. The results of that byte swapping are shown in FIG. 2B. It can be seen that the order of the two 16-bit pixels has been correctly converted from P1, P0 to P0, P1, but that the pixels themselves have become "scrambled" as a result of their bytes being swapped. In particular, note how the G field in each pixel has been split into two non-contiguous fields, the left-most one occupying the most-significant 3 bits of the pixel and the right-most one occupying the least-significant 2 bits of the pixel. Also, the remaining .alpha., R and B fields are no longer in the proper order.
Similar "pixel scrambling" problems occur when other pixel formats, such as .alpha.RGB 32 bpp (.alpha.=8 bits; R=8 bits; G=8 bits; and B=8 bits), are transferred between mixed-endian systems. Thus, before such pixels can be stored into the BE frame buffer, some mechanism for unscrambling needs to be in place.
The U.S. Patent cited above fails to mention the problem associated with mixed-endian systems, and so is of no help in addressing this problem.
A publication entitled PCI Multimedia Design Guide, Revision 1.0 (Mar. 29, 1994), which is distributed by the PCI Multimedia Working Group (part of the PCI Special Interest Group, P.O. Box 14070, Portland, Oreg. 97214), does briefly describe, on pages 17-18, the endian-ness conversion problem associated with pixels. There it is suggested that a technique similar to the address aliasing technique, referred to above, be employed to enable a frame buffer controller to detect whether a device is trying to access a LE or BE "aperture" in the frame buffer. If for example, a BE frame buffer controller detects an access request to a LE aperture, the frame buffer controller must, before storing the pixels into the frame buffer, first reorder them without scrambling. Detecting the need for a conversion would be based on a type tag in the address, similar to the pixel type tag described in the Atkins patent. However, the PCI Multimedia Design Guide is silent concerning any implementation for appropriately converting the pixel data.